Method and apparatus for enabling the detection of transparent defects

ABSTRACT

The present invention enables the network to determine the true state of events that appear normal but produce service disruptions by periodically probing the status of all network elements and endpoints and comparing this status to historical graphs of the network. Events that deviate from a historical view will be alarmed to determine their true status.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 11/049,383, filed Feb. 2, 2005, entitled, “METHOD AND APPARATUSFOR ENABLING THE DETECTION OF TRANSPARENT DEFECTS”, which has beenallowed. The aforementioned related patent application is hereinincorporated by reference.

BACKGROUND OF THE INVENTION

In communication networks, customer impacting disruptions sometimesoccur. Most of these disruptions produce alarms that allow networkoperators to quickly restore service. Occasionally, however, defects inthe network occur and are masked as normal events. For example sometimesthe network fails to detect the active status of an endpoint connectedto it and sends a call destined to that endpoint directly to voicemail.This event occurs because of a miscommunication between the endpoint andthe network and not because the endpoint is truly unavailable. Since thenetwork is temporarily blind to the true status of the endpoint, thistype of event is treated as normal even though customers are impacted bynot being able to receive calls.

Therefore, a need exists for a method and apparatus for enabling thedetection of transparent defects in packet switched networks, e.g., VoIPnetworks.

SUMMARY OF THE INVENTION

In one embodiment, the present invention enables the network todetermine the true state of events that appear normal but produceservice disruptions by periodically probing the status of all networkelements and endpoints and comparing this status to historical trends ofthe network. Events that deviate from a historical view will be alarmedto determine their true status. For example, a historical analysis maysuggest that at a certain point during the day, 20% of endpoints shouldbe unreachable and therefore subject to receiving voicemail, if a probedetermines a fluctuation in the current data from this historical trend,network operators will be alerted so that they can further investigatethe health of the network.

BRIEF DESCRIPTION OF THE DRAWINGS

The teaching of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 illustrates an exemplary Voice over Internet Protocol (VoIP)network related to the present invention;

FIG. 2 illustrates an example of enabling the detection of transparentdefects in a VoIP network of the present invention;

FIG. 3 illustrates a flowchart of a method for collecting historicaltrend data of call volumes and call flows in a VoIP network of thepresent invention;

FIG. 4 illustrates a flowchart of a method for analyzing historicaltrend data of call volumes and call flows to detect transparent defectsin a VoIP network of the present invention; and

FIG. 5 illustrates a high level block diagram of a general purposecomputer suitable for use in performing the functions described herein.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION

To better understand the present invention, FIG. 1 illustrates anexample network, e.g., a packet-switched network such as a VoIP networkrelated to the present invention. The VoIP network may comprise varioustypes of customer endpoint devices connected via various types of accessnetworks to a carrier (a service provider) VoIP core infrastructure overan Internet Protocol/Multi-Protocol Label Switching (IP/MPLS) based corebackbone network. Broadly defined, a VoIP network is a network that iscapable of carrying voice signals as packetized data over an IP network.An IP network is broadly defined as a network that uses InternetProtocol to exchange data packets.

The customer endpoint devices can be either Time Division Multiplexing(TDM) based or IP based. TDM based customer endpoint devices 122, 123,134, and 135 typically comprise of TDM phones or Private Branch Exchange(PBX). IP based customer endpoint devices 144 and 145 typically compriseIP phones or PBX. The Terminal Adaptors (TA) 132 and 133 are used toprovide necessary interworking functions between TDM customer endpointdevices, such as analog phones, and packet based access networktechnologies, such as Digital Subscriber Loop (DSL) or Cable broadbandaccess networks. TDM based customer endpoint devices access VoIPservices by using either a Public Switched Telephone Network (PSTN) 120,121 or a broadband access network via a TA 132 or 133. IP based customerendpoint devices access VoIP services by using a Local Area Network(LAN) 140 and 141 with a VoIP gateway or router 142 and 143,respectively.

The access networks can be either TDM or packet based. A TDM PSTN 120 or121 is used to support TDM customer endpoint devices connected viatraditional phone lines. A packet based access network, such as FrameRelay, ATM, Ethernet or IP, is used to support IP based customerendpoint devices via a customer LAN, e.g., 140 with a VoIP gateway androuter 142. A packet based access network 130 or 131, such as DSL orCable, when used together with a TA 132 or 133, is used to support TDMbased customer endpoint devices.

The core VoIP infrastructure comprises of several key VoIP components,such the Border Element (BE) 112 and 113, the Call Control Element (CCE)111, and VoIP related servers 114. The BE resides at the edge of theVoIP core infrastructure and interfaces with customers endpoints overvarious types of access networks. A BE is typically implemented as aMedia Gateway and performs signaling, media control, security, and calladmission control and related functions. The CCE resides within the VoIPinfrastructure and is connected to the BEs using the Session InitiationProtocol (SIP) over the underlying IP/MPLS based core backbone network110. The CCE is typically implemented as a Media Gateway Controller andperforms network wide call control related functions as well asinteracts with the appropriate VoIP service related servers whennecessary. The CCE functions as a SIP back-to-back user agent and is asignaling endpoint for all call legs between all BEs and the CCE. TheCCE may need to interact with various VoIP related servers in order tocomplete a call that require certain service specific features, e.g.translation of an E.164 voice network address into an IP address.

For calls that originate or terminate in a different carrier, they canbe handled through the PSTN 120 and 121 or the Partner IP Carrier 160interconnections. For originating or terminating TDM calls, they can behandled via existing PSTN interconnections to the other carrier. Fororiginating or terminating VoIP calls, they can be handled via thePartner IP carrier interface 160 to the other carrier.

In order to illustrate how the different components operate to support aVoIP call, the following call scenario is used to illustrate how a VoIPcall is setup between two customer endpoints. A customer using IP device144 at location A places a call to another customer at location Z usingTDM device 135. During the call setup, a setup signaling message is sentfrom IP device 144, through the LAN 140, the VoIP Gateway/Router 142,and the associated packet based access network, to BE 112. BE 112 willthen send a setup signaling message, such as a SIP-INVITE message if SIPis used, to CCE 111. CCE 111 looks at the called party information andqueries the necessary VoIP service related server 114 to obtain theinformation to complete this call. If BE 113 needs to be involved incompleting the call; CCE 111 sends another call setup message, such as aSIP-INVITE message if SIP is used, to BE 113. Upon receiving the callsetup message, BE 113 forwards the call setup message, via broadbandnetwork 131, to TA 133. TA 133 then identifies the appropriate TDMdevice 135 and rings that device. Once the call is accepted at locationZ by the called party, a call acknowledgement signaling message, such asa SIP-ACK message if SIP is used, is sent in the reverse direction backto the CCE 111. After the CCE 111 receives the call acknowledgementmessage, it will then send a call acknowledgement signaling message,such as a SIP-ACK message if SIP is used, toward the calling party. Inaddition, the CCE 111 also provides the necessary information of thecall to both BE 112 and BE 113 so that the call data exchange canproceed directly between BE 112 and BE 113. The call signaling path 150and the call data path 151 are illustratively shown in FIG. 1. Note thatthe call signaling path and the call data path are different becauseonce a call has been setup up between two endpoints, the CCE 111 doesnot need to be in the data path for actual direct data exchange.

Note that a customer in location A using any endpoint device type withits associated access network type can communicate with another customerin location Z using any endpoint device type with its associated networktype as well. For instance, a customer at location A using IP customerendpoint device 144 with packet based access network 140 can callanother customer at location Z using TDM endpoint device 123 with PSTNaccess network 121. The BEs 112 and 113 are responsible for thenecessary signaling protocol translation, e.g., SS7 to and from SIP, andmedia format conversion, such as TDM voice format to and from IP basedpacket voice format.

In VoIP networks customer impacting disruptions sometimes occur. Most ofthese disruptions produce alarms that allow network operators to quicklyrestore service. Occasionally, however, defects in the network occur andare masked as normal events. For example sometimes the network fails todetect the active status of an endpoint connected to it and sends a calldestined to that endpoint directly to voicemail. This event occursbecause of a miscommunication between the endpoint and the network andnot because the endpoint is truly unavailable. Since the network istemporarily blind to the true status of the endpoint, this type of eventis treated as normal even though customers are impacted by not beingable to receive calls.

To address this criticality, the present invention enables the networkto determine the true state of events that appear normal but produceservice disruptions by periodically probing the status of all networkelements and endpoints and comparing this status to historical graphs ofthe network. Events that deviate from a historical view will be alarmedto determine their true status. For example, a historical analysis maysuggest that at a certain point during the day, 20% of endpoints shouldbe unreachable and therefore subject to receiving voicemail, if a probedetermines a fluctuation in the current data from this historical trend,network operators will be alerted so that they can further investigatethe health of the network.

FIG. 2 illustrates an example of enabling the detection of transparentdefects in a packet-switched network, e.g., a VoIP network. In FIG. 2,the Network Management System (NMS) 214 periodically probes all networkelements and connected endpoint devices to collect call volumes and callflows status data, flow 250. Network elements include CCE 211, BEs 212,213, VoIP related AS 215 and endpoint devices include customer VoIPgateway or router 242 and Terminal Adaptor 231. The length of the periodof collection (e.g., a predefined collection period) is a configurableparameter predefined by the network provider and should be at least on afive minutes basis in one embodiment. Data collected within the currentperiod will be used to create a historical trend data point. Thecollected historical trend data point will be stored for furtheranalysis. When a period of historical data point is stored, thecollection of historical data points will be repeated for the nextperiod of time.

Once the current period of historical data point is stored, it can beused as a reference to compare against other previously collectedhistorical data points. The previously collected historical data pointto be compared include those from the previous five minutes, the sametime period from the previous 24 hours, or the same time period from theprevious week and it can be configured by the network provider for whichone to use. When a significant difference is detected based on thecomparisons, a transparent defect alarm will be raised to inform thenetwork provider of the problems. For instance, a historical analysismay suggest that the same time period from the previous week, 20% ofendpoints were unreachable and therefore subject to receiving voicemail.When the current historical trend data point shows that 40% of endpointswere unreachable, then the network operators will be alerted so thatthey can further investigate the health of the network. When thecomparison of the current period of historical data is completed, thenext period will be used as a reference point for the next comparison.

FIG. 3 illustrates a flowchart of a method for collecting historicaltrend data of call volume and call flow by the NMS of a packet switchednetwork, e.g., a VoIP network. Method 300 starts in step 305 andproceeds to step 310.

In step 310, the method collects call volume and call flow data from allnetwork elements and connected endpoint devices from the VoIP network.The call volume measures the number of calls processed by the networkand the call flow measures the type of calls, such as calls successfullycompleted, calls fail to be completed, and calls destined to voicemail,processed by the network. In step 320, the method creates a currenthistorical trend data point using data collected within the currentperiod. In step 330, the method stores the current historical data pointfor the current period based on time of date. In step 340, the methodwaits for the next period to begin and proceeds back to step 310.

FIG. 4 illustrates a flowchart of a method for analyzing historicaltrend data of call volume and call flow by the NMS to detect transparentdefects in a packet switched network, e.g., a VoIP network. Method 400starts in step 405 and proceeds to step 410.

In step 410, the method retrieves stored historical data points foranalysis. In step 420, the method selects the current period ofhistorical data point as the reference point for comparison. In step430, the method compares the current period historical data pointagainst a pre-selected previous period of historical data point toproduce difference data. In step 440, the method checks if there issignificant differences between the current and the previous historicaldata points. If a call volume and call flow data trend differenceexceeds a predefined threshold set by the network provider, then themethod proceeds to step 450; otherwise, the method proceeds to step 460.In step 450, the method raises an alarm warning the network providerthat an abnormal call volume and call flow trend has been detected. Instep 460, the method waits for the next period to begin and proceedsback to step 410.

FIG. 5 depicts a high level block diagram of a general purpose computersuitable for use in performing the functions described herein. Asdepicted in FIG. 5, the system 500 comprises a processor element 502(e.g., a CPU), a memory 504, e.g., random access memory (RAM) and/orread only memory (ROM), a detection of transparent defects module 505,and various input/output devices 506 (e.g., storage devices, includingbut not limited to, a tape drive, a floppy drive, a hard disk drive or acompact disk drive, a receiver, a transmitter, a speaker, a display, aspeech synthesizer, an output port, and a user input device (such as akeyboard, a keypad, a mouse, and the like)).

It should be noted that the present invention can be implemented insoftware and/or in a combination of software and hardware, e.g., usingapplication specific integrated circuits (ASIC), a general purposecomputer or any other hardware equivalents. In one embodiment, thepresent detection of transparent defects module or process 505 can beloaded into memory 504 and executed by processor 502 to implement thefunctions as discussed above. As such, the present detection oftransparent defects process 505 (including associated data structures)of the present invention can be stored on a computer readable medium orcarrier, e.g., RAM memory, magnetic or optical drive or diskette and thelike.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

1. A method for detecting defects in a communication network,comprising: collecting data associated with at least one of: a callvolume from a plurality of network elements, or a call flow from aplurality of network elements; comparing a current period of data withat least one previous period of historical data to produce differencedata; and raising an alarm if said difference data exceeds a predefinedthreshold.
 2. The method of claim 1, wherein said communication networkis a Voice over Internet Protocol (VoIP) network.
 3. The method of claim1, wherein data is collected periodically for a predefined collectionperiod.
 4. The method of claim 1, wherein said predefined threshold is aconfigurable parameter.
 5. A computer-readable medium having storedthereon a plurality of instructions, the plurality of instructionsincluding instructions which, when executed by a processor, cause theprocessor to perform the steps of a method for detecting defects in acommunication network, comprising: collecting data associated with atleast one of: a call volume from a plurality of network elements, or acall flow from a plurality of network elements; comparing a currentperiod of data with at least one previous period of historical data toproduce difference data; and raising an alarm if said difference dataexceeds a predefined threshold.
 6. The computer-readable medium of claim5, wherein said communication network is a Voice over Internet Protocol(VoIP) network.
 7. The computer-readable medium of claim 5, wherein datais collected periodically for a predefined collection period.
 8. Thecomputer-readable medium of claim 5, wherein said predefined thresholdis a configurable parameter.
 9. A system for detecting defects in acommunication network, comprising: means for collecting data associatedwith at least one of: a call volume from a plurality of networkelements, or a call flow from a plurality of network elements; means forcomparing a current period of data with at least one previous period ofhistorical data to produce difference data; and means for raising analarm if said difference data exceeds a predefined threshold.
 10. Thesystem of claim 9, wherein said communication network is a Voice overInternet Protocol (VoIP) network.
 11. The system of claim 9, whereindata is collected periodically for a predefined collection period. 12.The system of claim 11, wherein a length of said collection period is atleast on a five-minute basis.
 13. The system of claim 9, wherein said atleast one previous period comprises at least one of: a previous fiveminute period, a same period of a previous day, or a same period of aprevious week.
 14. The system of claim 9, wherein said collecting meansstores said data associated with at least one of: a call volume fromsaid plurality of network elements, or a call flow from said pluralityof network elements based on time of date.
 15. The system of claim 9,wherein said call volume is a measure of a number of calls processed byone of said plurality of network elements, and wherein said call flow isa measure of a type of calls processed by one of said plurality ofnetwork elements.
 16. The system of claim 15, wherein said type of callscomprises at least one of: a successfully completed call, a calldestined to a voicemail box, or a call that fails to be completed.